1. Field of the Invention
Embodiments of the invention described herein pertain to the field of computer systems. More particularly, but not by way of limitation, one or more embodiments of the invention enable a lock management system and method.
2. Description of the Related Art
In a multi-threaded computing environment, resource objects must be shared between multiple threads. Applications running in a multi-threaded environment must be designed to avoid conflicts due to the access of shared resources, such as memory, hardware and data. Locking is a widespread technique used to address this concern. Locking prevents the use of a shared resource by more than one operation at a time. When an operation has an exclusive lock on a shared resource, it becomes unavailable to others. Concurrency control preserves resource consistency and resolves conflicts. In the management of shared data resources, locking secures the permission to access a data item during a transaction. Unlocking removes the permissions from the data item so that other processes and operations may move forward and access the shared resource in turn.
Proper locking implementation in an application running in a multi-threaded environment is complex. On one hand, under locking in an application is problematic because problems will occur that locking and lock management are designed to avoid. On the other hand, over locking can also create problems, such as deadlocking and performance degradation. Such problems are also exacerbated by poor coding practices. Lock implementation is an important and time-consuming part of application design. Improper implementation and management of locking may result in inefficiency and errors, such as deadlocks, race conditions, hanging, poor performance, exceptions, program termination, data corruption, and many other issues. Thus, improper lock management can result in high costs in terms of debugging, support and maintenance costs.
Lock escalation policies may be used to broaden access to a resource, such as a database. For example, a resource may be unlocked when a session is accessing the resource. Alternatively, one or more sessions may have a shared lock on a resource. Typically, a shared lock is granted when the session requests read access of the resource. A session may also have an exclusive lock on a resource. Typically, an exclusive lock is required when a modification, including a deletion and addition, is made to the resource. A lock management system may include refinement to enhance efficiency and consistency. For example, a lock management system may define a method for determining the priority of sessions which request a type of lock. Furthermore, an exclusive lock may be divided up into further locking states such that modifications are first cached before being written in a writing step.
In two-phase locking techniques, shared locks are used to provide read access to multiple transactions, while exclusive access is granted for write access. In the prior art, two-phase locking techniques use a lock manager which manages locks on all data items. A lock table may also be used to store the transaction, data item locked, and lock mode.
The granularity of lock management systems may vary. In coarse-grained locking, when a session is writing to a database, all other sessions are locked out until the transaction is completed. Fine-grained locking locks a tuple or attribute. In a database, granularity can range from a single field, a record, a table, one or more disc blocks, an entire table, or an entire database. Locking helps maintain the integrity of the data in a database by ensuring that the same data or related structures to the data are not modified in two different processes or operations concurrently. A lock management system for a database may be optimized to include functionality to implement multiple granularity levels in a single database lock management system.
When collections of objects are accessed by complex programs, they all need to be locked correctly and consistently. Even when a complex lock management system is available, code reuse and development typical for software projects tends to encourage developers to take an excessively pessimistic locking approach in order to avoid incurring severe support and maintenance costs due to insufficient locking. Currently, programmers have to choose lock types based on the context of the operation. Improper lock implementation by a programmer may result in problematic compiled code with poor performance.
Typically, a simple lock management system provides straightforward application design, implementation, and debugging. However, simple lock management systems typically do handle locking efficiently. On the other hand, an optimized lock management system provides more efficient access to shared resources, such as a database. However, software development becomes more complicated, and developers may not take advantage of the optimized system because of its complexity, especially in software projects involving multiple developers.
For at least the limitations described above there is a need for a system and method for automation of consistent lock management.